I agree with you. Requiring multiple interface files per class is a bad idea. Developers have enough of a burden managing changes between the .h and the .m, lets not *require* a third file.
Bill's goal of hiding implementation details is worthwhile, however I don't believe it should be limited to the "use" case. Encapsulation and modularity are important for both users and subclassers. Granting subclassers special access rights is often a premature optimization that "ties the hands" of library writers.
This isn't solely a language issue, development environments must share in the "blame". For example, you could imagine a tool that provides different "views" of an interface...implementors of a kit would see one view, users of a kit would see another view. The .h files would provide the "lowest level" view for constructing other views. In the NeXT environment, we have a tool called HeaderViewer for integrating access to headers and documentation...this is where we could provide filtered views (omit ivar declarations, etc).
On the language side, protocols provide support for clearly separating interface from implementation. Andrew, could you send me any feedback you have on protocols? I am really interested in seeing this feature flushed out...
To summarize, we should resist complicating the language if the problem is a lack of support from the software development environment. Unfortunately, it is often easier the change the language (given the diversity of environments we all work with).
Oh well,
snaroff.
btw...does "don't dislike" evaluate into "like" (or something less)?
From: greg@sce.carleton.ca (Greg Franks)
Date: Sat, 27 Feb 93 18:05:37 EST
To: gnu-objc@gnu.ai.mit.edu
In-Reply-To: Steve Naroff's message of Sat, 27 Feb 93 08:46:49 -0800 <9302271647.AA09458@oz.NeXT.COM>
Subject: Use/Subclass Interface distinction
Steve_Naroff@NeXT.COM (Steve Naroff) writes:
> I agree with you. Requiring multiple interface files per class is a
> bad idea. Developers have enough of a burden managing changes between
> the .h and the .m, lets not *require* a third file.
However, the .h file can be generated automatically from the .m file.,
so an '.if' file (or whatever) can be too.
We here at Carleton already have a simple shell script to manage